erDiagram
STYLIST {
int stylistID
string name
string experienceLvl
string contact
}
CLIENT {
string clientID
string name
string contact
string shirtSize
string pantSize
string shoeSize
}
OUTFIT {
int outfitID
string name
date dateCreated
string style
}
PIECE {
string piID
string type
string color
string size
string material
string brand
}
STYLIST ||--|{ CLIENT : "has"
STYLIST ||--|{ OUTFIT : "makes"
OUTFIT }|--|{ PIECE : "contains"
Data Dynamos Project Proposal
Overview
This project focuses on the vital role of stylists, who curate the visual aesthetic of individuals, brands, and public figures by selecting and crafting outfits that shape how the world perceives them. Stylists are more than just fashion experts—they are artists who use clothing to tell powerful stories, influence trends, and create iconic looks. Our database will assist stylists in managing large wardrobes, streamlining the process of putting together cohesive looks, and reducing the challenges they face in their day-to-day work.
Deliverables
Problem Description
Problem Domain
A stylist is a professional who curates and crafts the perfect looks for individuals, brands, or public figures. They are the masterminds behind a person’s complete visual aesthetic, orchestrating not only what someone wears but how they wear it, to create a cohesive, striking image. More than just selecting outfits, stylists shape how the world perceives many of our favorite brands, celebrities, and influencers. Through their knack for design and creativity, they have the power to control and influence entire narratives, telling stories through fashion alone. These talented professionals are the unsung artists behind some of the most iconic and unforgettable looks in fashion history. With clothing as their medium, stylists bring their artistic vision to life, creating statements that not only define trends but also immortalize moments in culture.
Need
Our database is essential for stylists who manage numerous clients with extensive wardrobes. Given the vast amount of clothing celebrities receive through PR packages and events, it can be overwhelming to keep track of everything. This challenge is compounded by the difficulty of scheduling in-person fittings. Our database addresses these issues by providing a centralized platform where stylists can efficiently organize and access their clients’ clothing inventory. This system allows stylists to style clients remotely, reducing the need for physical meetings. Additionally, it helps combat overconsumption by ensuring that no piece of clothing is overlooked. Ultimately, our database streamlines the styling process, making it easier for stylists to manage their clients’ wardrobes effectively.
Context, Scope and Perspective
The fashion industry is a multi-billion dollar industry, comprised of many different components that work together to make it what it is today. Fashion is a collaboration between many talented models, designers, and stylists who come together to create looks that are, essentially, a form of art. Our focus is to specifically support the stylists, the creative minds responsible for shaping trends and helping people express themselves through style. While our goal is to tailor this to stylists, we truly believe that what we’re offering can be beneficial to anyone who’s interested in fashion or personal expression. It’s something we see as useful and accessible for everyone.
User Roles and Use Cases
User Roles
- Stylist (Primary User)
- Needs: Stylists need an organized system to manage multiple clients’ wardrobes, including cataloging clothing and tracking outfits.
- Use of Database: Stylists will log in to the database to add, update, or delete wardrobe items for each client. They can also browse clients’ inventories remotely, create outfit plans, and manage events. This eliminates the need for physical wardrobe inspections, allowing them to create style suggestions remotely and streamline the fitting process.
- Interactions: They will frequently add new items to the database, tag them by category, and schedule appointments. They may also use data to provide clients with tailored looks for specific events.
- Client (Secondary User)
- Needs: Clients need visibility into their wardrobe inventory curated by the stylist. They may want to preview outfits selected by their stylist and track clothing used in past events.
- Use of Database: Clients will access a read-only version of their wardrobe inventory. They will be able to review outfits planned for upcoming events and provide feedback or make requests for alterations. This allows them to stay informed about their wardrobe without being physically present.
- Interactions: Clients will log in to review their wardrobe and upcoming event outfits, as well as provide input or request specific items to be styled.
- Fashion Brand PR Team (Tertiary User)
- Needs: Fashion brands often send new collections to stylists for their clients, and they need a way to track the clothing sent and whether it’s being used.
- Use of Database: PR teams will have limited access to the system, allowing them to view which pieces from their collections are currently part of a client’s wardrobe. This ensures they can track the visibility and use of their clothing in public events.
- Interactions: PR teams can log in to see if their garments are actively being styled or are part of planned outfits for high-profile events.
Use Cases
- Stylist Managing Wardrobe Inventory
- Stylists can add new pieces from PR packages, categorize them (e.g., casual, formal, seasonal), and tag them by client. They can access the database on-the-go, allowing real-time updates during fittings or client meetings.
- Stylist Creating Outfit Plans
- Stylists can browse a client’s inventory, select multiple pieces, and save outfit suggestions. These plans can be linked to specific events (e.g., award shows, photoshoots) and shared with the client for review and approval.
- Clients Viewing Outfits and Pieces
- Clients can view outfits that have been assembled to find something to wear, and view indivdual pieces to see what’s in their closet.
Database Connectivity:
The database will be connected to:
- Fashion Brand Platforms: Allows easy import of new collections and clothing lines from fashion brands.
- Web Application: Stylists and clients will be able to access the database via a web application, ensuring on-the-go wardrobe management.
This approach will enhance collaboration between stylists, clients, and fashion brands, while reducing inefficiencies in the wardrobe management process.
Security and Privacy
To ensure the utmost privacy and security, our database design will prioritize safeguarding sensitive client information, especially when dealing with celebrity clients whose contact details and personal data require strict confidentiality. Given that many stylists will have access to this information, implementing robust security measures is essential to maintain client trust and protect their privacy.
Database Design
Entity-Relationship Diagram (ERD)
Relational Schemas
Stylist
Stylist(stylistID [PK], name [NOT NULL], experienceLvl [NOT NULL], contact [NOT NULL])
| Key | Variable | Type | Domain | Constraint |
|---|---|---|---|---|
| PK | stylistID | INT | Positive integers | PRIMARY KEY |
| name | VARCHAR(100) | Text up to 100 chars | NOT NULL | |
| experienceLvl | VARCHAR(100) | 1-12 (Beginner, Intermmediate, Expert) | NOT NULL | |
| contact | VARCHAR(100) | Valid email format | NOT NULL, UNIQUE |
Client
Client(clientID [PK], name [NOT NULL], contact [NOT NULL], shirtSize [NOTNULL], pantSize [NOTNULL], shoeSize [NOTNULL])
| Key | Variable | Type | Domain | Constraint |
|---|---|---|---|---|
| PK | clientID | INT | Positive integers | PRIMARY KEY |
| name | VARCHAR(100) | Text up to 100 chars | NOT NULL | |
| contact | VARCHAR(100) | Valid email format | NOT NULL, UNIQUE | |
| shirtSize | VARCHAR(6) | 1-6 (Small, Medium, Large) | NULLABLE | |
| pantSize | VARCHAR(6) | 1-6 (Small, Medium, Large) | NULLABLE | |
| shoeSize | VARCHAR(6) | 1-6 (Small, Medium, Large) | NULLABLE |
Piece
Piece(pieceID [PK], type [NOT NULL], color, material, brand, size)
| Key | Variable | Type | Domain | Constraint |
|---|---|---|---|---|
| PK | pieceID | INT | Positive integers | PRIMARY KEY |
| type | VARCHAR(50) | Clothing types (e.g., top, bottom) | NOT NULL | |
| color | VARCHAR(30) | Standard color names | NULLABLE | |
| material | VARCHAR(50) | Materials (e.g., cotton, polyester) | NULLABLE | |
| brand | VARCHAR(50) | Text up to 50 chars | NULLABLE | |
| size | VARCHAR(6) | 1-6 (Small, Medium, Large) | NULLABLE |
Outfit
Outfit(outfitID [PK], stylistID [FK], style [NOT NULL], dateCreated [NOT NULL])
| Key | Variable | Type | Domain | Constraint |
|---|---|---|---|---|
| PK | outfitID | INT | Positive integers | PRIMARY KEY |
| style | VARCHAR(50) | Formal, casual, steetwear etc. | NOT NULL | |
| dateCreated | DATE | YYYY-MM-DD format | NOT NULL |
OutfitPiece
OutfitPiece(outfitID [FK], pieceID [FK])
| Key | Variable | Type | Domain | Constraint |
|---|---|---|---|---|
| FK | outfitID | INT | Must exist in Outfit | FOREIGN KEY REFERENCES Outfit(outfitID) |
| FK | pieceID | INT | Must exist in Piece | FOREIGN KEY REFERENCES Piece(pieceID) |
StylistClient
StylistClient(stylistID [FK], clientID [FK])
| Key | Variable | Type | Domain | Constraint |
|---|---|---|---|---|
| FK | stylistID | INT | Must exist in Stylist | FOREIGN KEY REFERENCES Stylist(stylistID) |
| FK | clientID | INT | Must exist in Client | FOREIGN KEY REFERENCES Client(clientID) |
Functional Dependencies and Normalization
Step 1: Identify Functional Dependencies
For each table, we’ve identified the functional dependencies, which describe how one attribute depends on another:
- Stylist:
- Functional Dependencies:
stylistID → name, experienceLvl, contact - Explanation:
stylistIDuniquely determines all other attributes in the table, with no additional dependencies, so this table is already in BCNF.
- Functional Dependencies:
- Client:
- Functional Dependencies:
clientID → name, contact, shirtSize, pantSize, shoeSize - Explanation:
clientIDuniquely determines each attribute in the Client table, meaning that no further decomposition is needed for BCNF.
- Functional Dependencies:
- Outfit:
- Functional Dependencies:
outfitID → name, style, dateCreated - Explanation: In the Outfit table,
outfitIDdetermiens all other attributes, so no additional dependencies exist, keeping the table in BCNF.
- Functional Dependencies:
- Piece:
- Functional Dependencies:
pieceID → type, color, size, material, brand - Explanation: Each attribute is fully dependent on
pieceID, meaning this table is already in BCNF.
- Functional Dependencies:
Step 2: Normalize to BCNF/4NF
Each table satisfies BCNF because:
- All tables have a single primary key that uniquely determines all other attributes, which is the definition of BCNF. There are no partial dependencies.
- Every functional dependency in each table has a super key as its determinant.
Step 3: Lossless Decomposition
In this case:
- Stylist, Client, Outfit, and Piece tables already meet BCNF requirements without any more decomposition. The relationships between tables (like StylistClient and OutfitPiece) allow us to maintain a lossless structure.
- Relationship Tables:
- StylistClient: This associative table with
stylistIDandclientIDas a composite primary key satisfies BCNF/4NF since each combination of stylist and client is unique. - OutfitPiece: This table has a composite primary key with
outfitIDandpieceID, meaning no redundant data or multi-valued dependencies exist. It also meets BCNF/4NF requirements.
- StylistClient: This associative table with
The database schema is structured so that any data split across the tables can be recombined by joins on primary and foreign keys, achieving a lossless decomposition.
Conclusion
This schema is fully normalized to BCNF. All tables and associative tables meet these forms By following the normalization process step-by-step, we ensured that the design satisfies the requirements for an efficient, well-structured database that can be expanded or modified with minimal risk of issues.